Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9701/000019_owner-urn-ietf _Wed Jan 29 18:40:35 1997.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA14105 for urn-ietf-out; Wed, 29 Jan 1997 18:40:35 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA14100 for <[e-mail]>; Wed, 29 Jan 1997 18:40:32 -0500
Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA08833  (mail destined for [e-mail]); Wed, 29 Jan 97 18:40:24 -0500
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
          id SAA31944; Wed, 29 Jan 1997 18:35:05 -0500 (EST)
Message-Id: <[e-mail]>
X-Uri: http://www.cs.utk.edu/~moore/
From: Keith Moore <[e-mail]>
To: Tim Berners-Lee <[e-mail]>
Cc: Keith Moore <[e-mail]>, Daniel LaLiberte <[e-mail]>,
        "Martin J. Duerst" <[e-mail]>,
        "Ron Daniel Jr." <[e-mail]>,
        URL mailing list <[e-mail]>, [e-mail]
Subject: [URN] Re: Relative URLs and URNs
In-Reply-To: Your message of "Wed, 29 Jan 1997 17:46:52 EST."
             <[e-mail]>
Date: Wed, 29 Jan 1997 18:35:05 -0500
Sender: [e-mail]
Precedence: bulk
Reply-To: Keith Moore <[e-mail]>
Errors-To: [e-mail]

> >> If all URNs are syntactically opaque URLs, are we not imposing a
> >> restriction on all URNs that they cannot use the relative URL mechanism?
> >
> >Yes, but this is a feature.  Relative URLs wire relationships between
> >resources into the resource name itself, which hurts long-term persistence.
>
> Keith, you make a good point that relative URIs are limited in persistence to
> the persistence of the two URIs.

I don't know which two URIs you're talking about.  The persistence
problem, as I see it, comes from wiring non-persistent information
into the URI -- in this case, the grouping of subsets of URI space --
and depending on that information to be persistent.

> But Dan La L was right too in pointing  out that
> the relative URI may in fact be longer lived than the absolute. So it is
> not a clear case.

Unless I misunderstood his argument, it seemed to be predicated on
the idea that old name spaces will go away and need to be changed.
But since the URN framework is specifically designed so that old name
spaces do not need to be changed, I don't accept the premise.

As far as I can tell, if we're going to have persistent relative URNs
(or equivalently, URNs that reference portions of a single resource)
we're going to need a level of indirection for relative URNs just like
we have for normal URNs.

That is,

given a resource a1 with URN "A1" and a similar resource a2 with URN "A2",
(for some meaning of "similar"), it's not reasonable to assume that
the portion of a1 named by "A1/foo" is similar to the portion of
a2 named by "A2/foo".  What we would need is some mapping layer which
we could ask "what portion of a2 is equivalent to the portion of a1 named
by "A1/foo"?".  (and just because "A1/foo" maps to "A2/bar" doesn't
mean that A2/bar maps to A1/foo)

> So one should not forbid them.  Disabling a consistent function in a special
> case is normally a kludge, not a feature.  In general, specs which tell
> people what to do against their better judgement are typically suspect too.
> This would be something to put in a usage document: "When relative
> URIs are considered harmful and when not"

My view is that since persistence is an important property of URNs,
we should not define relative URNs (or URNs that specify portions of
documents) until we understand how to define them without diluting
the persistence of URNs.

If we disallow unencoded '/' within URNs for now, we can always add
relative URNs later when we understand them better.

Keith